drm/vmwgfx: fix integer overflow in vmw_surface_define_ioctl()

In vmw_surface_define_ioctl(), the 'num_sizes' is the sum of the
'req->mip_levels' array. This array can be assigned any value from
the user space. As both the 'num_sizes' and the array is uint32_t,
it is easy to make 'num_sizes' overflow. The later 'mip_levels' is
used as the loop count. This can lead an oob write. Add the check of
'req->mip_levels' to avoid this.

Signed-off-by: Li Qiang <liqiang6-s@360.cn>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name drm-vmwgfx-fix-integer-overflow-in-vmw_surface_define_ioctl.patch

vmwgfx: NULL pointer dereference in vmw_surface_define_ioctl()

Before memory allocations vmw_surface_define_ioctl() checks the
upper-bounds of a user-supplied size, but does not check if the
supplied size is 0.

Add check to avoid NULL pointer dereferences.

Signed-off-by: Murray McAllister <murray.mcallister@insomniasec.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
[bwh: Fix filename]

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name vmwgfx-null-pointer-dereference-in-vmw_surface_define_ioctl.patch

scsi: sg: check length passed to SG_NEXT_CMD_LEN

The user can control the size of the next command passed along, but the
value passed to the ioctl isn't checked against the usable max command
size.

Cc: <stable@vger.kernel.org>
Signed-off-by: Peter Chang <dpf@google.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name scsi-sg-check-length-passed-to-sg_next_cmd_len.patch

xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder

Kees Cook has pointed out that xfrm_replay_state_esn_len() is subject to
wrapping issues.  To ensure we are correctly ensuring that the two ESN
structures are the same size compare both the overall size as reported
by xfrm_replay_state_esn_len() and the internal length are the same.

CVE-2017-7184
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name xfrm_user-validate-xfrm_msg_newae-incoming-esn-size-harder.patch

xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window

When a new xfrm state is created during an XFRM_MSG_NEWSA call we validate
the user supplied replay_esn to ensure that the size is valid and to ensure
that the replay_window size is within the allocated buffer.  However later
it is possible to update this replay_esn via a XFRM_MSG_NEWAE call.
There we again validate the size of the supplied buffer matches the
existing state and if so inject the contents.  We do not at this point
check that the replay_window is within the allocated memory.  This leads
to out-of-bounds reads and writes triggered by netlink packets.  This leads
to memory corruption and the potential for priviledge escalation.

We already attempt to validate the incoming replay information in
xfrm_new_ae() via xfrm_replay_verify_len().  This confirms that the
user is not trying to change the size of the replay state buffer which
includes the replay_esn.  It however does not check the replay_window
remains within that buffer.  Add validation of the contained replay_window.

CVE-2017-7184
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name xfrm_user-validate-xfrm_msg_newae-xfrma_replay_esn_val-replay_window.patch

sctp: deny peeloff operation on asocs with threads sleeping on it

commit 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
attempted to avoid a BUG_ON call when the association being used for a
sendmsg() is blocked waiting for more sndbuf and another thread did a
peeloff operation on such asoc, moving it to another socket.

As Ben Hutchings noticed, then in such case it would return without
locking back the socket and would cause two unlocks in a row.

Further analysis also revealed that it could allow a double free if the
application managed to peeloff the asoc that is created during the
sendmsg call, because then sctp_sendmsg() would try to free the asoc
that was created only for that call.

This patch takes another approach. It will deny the peeloff operation
if there is a thread sleeping on the asoc, so this situation doesn't
exist anymore. This avoids the issues described above and also honors
the syscalls that are already being handled (it can be multiple sendmsg
calls).

Joint work with Xin Long.

Fixes: 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
Cc: Alexander Popov <alex.popov@linux.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name sctp-deny-peeloff-operation-on-asocs-with-threads-sl.patch

time: Mark TIMER_STATS as broken

This is a substitute for upstream commit dfb4357da6dd "time: Remove
CONFIG_TIMER_STATS", which avoids the need to resolve conflicts with
the PREEMPT_RT patch series.

Gbp-Pq: Topic debian
Gbp-Pq: Name time-mark-timer_stats-as-broken.patch

kvm: fix page struct leak in handle_vmon

handle_vmon gets a reference on VMXON region page,
but does not release it. Release the reference.

Found by syzkaller; based on a patch by Dmitry.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[bwh: Backported to 4.9: use skip_emulated_instruction()]

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name kvm-fix-page-struct-leak-in-handle_vmon.patch

PCI: Set pci=nobios by default

CONFIG_PCI_GOBIOS results in physical addresses 640KB-1MB being mapped
W+X, which is undesirable for security reasons and will result in a
warning at boot now that we enable CONFIG_DEBUG_WX.

This can be overridden using the kernel parameter "pci=nobios", but we
want to disable W+X by default.  Disable PCI BIOS probing by default;
it can still be enabled using "pci=bios".

Gbp-Pq: Topic debian
Gbp-Pq: Name i386-686-pae-pci-set-pci-nobios-by-default.patch

arm64: add kernel config option to set securelevel when in Secure Boot mode

Add a kernel configuration option to enable securelevel, to restrict
userspace's ability to modify the running kernel when UEFI Secure Boot is
enabled. Based on the x86 patch by Matthew Garrett.

Determine the state of Secure Boot in the EFI stub and pass this to the
kernel using the FDT.

Signed-off-by: Linn Crosetto <linn@hpe.com>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name arm64-add-kernel-config-option-to-set-securelevel-wh.patch

arm64/efi: Disable secure boot if shim is in insecure mode

Port to arm64 a patch originally written by Josh Boyer for the x86 EFI
stub.

A user can manually tell the shim boot loader to disable validation of
images it loads.  When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set.  Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.

Signed-off-by: Linn Crosetto <linn@hpe.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name arm64-efi-disable-secure-boot-if-shim-is-in-insecure.patch

mtd: Disable slram and phram when securelevel is enabled

The slram and phram drivers both allow mapping regions of physical
address space such that they can then be read and written by userland
through the MTD interface.  This is probably usable to manipulate
hardware into overwriting kernel code on many systems.  Prevent that
if securelevel is set.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name mtd-disable-slram-and-phram-when-securelevel-is-enabled.patch

Enable cold boot attack mitigation

Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name enable-cold-boot-attack-mitigation.patch

acpi: Disable APEI error injection if securelevel is set

ACPI provides an error injection mechanism, EINJ, for debugging and testing
the ACPI Platform Error Interface (APEI) and other RAS features. If
supported by the firmware, ACPI specification 5.0 and later provide for a
way to specify a physical memory address to which to inject the error.

Injecting errors through EINJ can produce errors which to the platform are
indistinguishable from real hardware errors. This can have undesirable
side-effects, such as causing the platform to mark hardware as needing
replacement.

While it does not provide a method to load unauthenticated privileged code,
the effect of these errors may persist across reboots and affect trust in
the underlying hardware, so disable error injection through EINJ if
securelevel is set.

Signed-off-by: Linn Crosetto <linn@hpe.com>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name acpi-disable-apei-error-injection-if-securelevel-is-.patch

acpi: Disable ACPI table override if securelevel is set

From the kernel documentation (initrd_table_override.txt):

  If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible
  to override nearly any ACPI table provided by the BIOS with an
  instrumented, modified one.

When securelevel is set, the kernel should disallow any unauthenticated
changes to kernel space. ACPI tables contain code invoked by the kernel, so
do not allow ACPI tables to be overridden if securelevel is set.

Signed-off-by: Linn Crosetto <linn@hpe.com>
[bwh: Forward-ported to 4.7: ACPI override code moved to drivers/acpi/tables.c]
[bwh: Forward-ported to 4.9: adjust context]

Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name acpi-disable-acpi-table-override-if-securelevel-is-s.patch

kexec/uefi: copy secure_boot flag in boot params across kexec reboot

Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load.  In this state, the system is missing the protections provided
by secure boot. Adding a patch to fix this by retain the secure_boot flag
in original kernel.

secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub. Fixing this issue by copying secure_boot flag across kexec reboot.

Signed-off-by: Dave Young <dyoung@redhat.com>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name kexec-uefi-copy-secure_boot-flag-in-boot-params-acro.patch

hibernate: Disable when securelevel is set

There is currently no way to verify the resume image when returning
from hibernate.  This might compromise the securelevel trust model,
so until we can work with signed hibernate images we disable it in
a secure modules environment.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name hibernate-disable-when-securelevel-is-set.patch

efi: Disable secure boot if shim is in insecure mode

A user can manually tell the shim boot loader to disable validation of
images it loads.  When a user does this, it creates a UEFI variable called
MokSBState that does not have the runtime attribute set.  Given that the
user explicitly disabled validation, we can honor that and not enable
secure boot mode if that variable is set.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name efi-disable-secure-boot-if-shim-is-in-insecure-mode.patch

Add option to automatically set securelevel when in Secure Boot mode

UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels. Certain use cases may also
require that the kernel prevent userspace from inserting untrusted kernel
code at runtime. Add a configuration option that enforces this automatically
when enabled.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name add-option-to-automatically-set-securelevel-when-in-.patch

asus-wmi: Restrict debugfs interface when securelevel is set

We have no way of validating what all of the Asus WMI methods do on a
given machine, and there's a risk that some will allow hardware state to
be manipulated in such a way that arbitrary code can be executed in the
kernel. Prevent that if securelevel is set.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name asus-wmi-restrict-debugfs-interface-when-securelevel.patch

x86: Restrict MSR access when securelevel is set

Permitting write access to MSRs allows userspace to modify the running
kernel. Prevent this if securelevel has been set. Based on a patch by Kees
Cook.

Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name x86-restrict-msr-access-when-securelevel-is-set.patch

uswsusp: Disable when securelevel is set

uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel. Disable this if securelevel
has been set.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name uswsusp-disable-when-securelevel-is-set.patch

kexec: Disable at runtime if securelevel has been set.

kexec permits the loading and execution of arbitrary code in ring 0, which
permits the modification of the running kernel. Prevent this if securelevel
has been set.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name kexec-disable-at-runtime-if-securelevel-has-been-set.patch

acpi: Ignore acpi_rsdp kernel parameter when securelevel is set

This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to execute arbitrary code in the kernel.
Disable this when securelevel is set.

Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name acpi-ignore-acpi_rsdp-kernel-parameter-when-securele.patch

acpi: Limit access to custom_method if securelevel is set

custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to modify the kernel at runtime. Prevent this
if securelevel has been set.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name acpi-limit-access-to-custom_method-if-securelevel-is.patch

Restrict /dev/mem and /dev/kmem when securelevel is set.

Allowing users to write to address space provides mechanisms that may permit
modification of the kernel at runtime. Prevent this if securelevel has been
set.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
[bwh: Forward-ported to 4.9: adjust context]

Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name restrict-dev-mem-and-dev-kmem-when-securelevel-is-se.patch

x86: Lock down IO port access when securelevel is enabled

IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO register
space. This would potentially permit root to trigger arbitrary DMA, so lock
it down when securelevel is set.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name x86-lock-down-io-port-access-when-securelevel-is-ena.patch

PCI: Lock down BAR access when securelevel is enabled

Any hardware that can potentially generate DMA has to be locked down from
userspace in order to avoid it being possible for an attacker to modify
kernel code. This should be prevented if securelevel has been set. Default
to paranoid - in future we can potentially relax this for sufficiently
IOMMU-isolated devices.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name pci-lock-down-bar-access-when-securelevel-is-enabled.patch

Enforce module signatures when securelevel is greater than 0

If securelevel has been set to 1 or greater, require that all modules have
valid signatures.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name enforce-module-signatures-when-securelevel-is-greate.patch

Add BSD-style securelevel support

Provide a coarse-grained runtime configuration option for restricting
userspace's ability to modify the running kernel.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Gbp-Pq: Topic features/all/securelevel
Gbp-Pq: Name add-bsd-style-securelevel-support.patch

netfilter: nft_ct: add notrack support

This patch adds notrack support.

I decided to add a new expression, given that this doesn't fit into the
existing set operation. Notrack doesn't need a source register, and an
hypothetical NFT_CT_NOTRACK key makes no sense since matching the
untracked state is done through NFT_CT_STATE.

I'm placing this new notrack expression into nft_ct.c, I think a single
module is too much.

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Gbp-Pq: Topic features/all
Gbp-Pq: Name netfilter-nft_ct-add-notrack-support.patch

ACPI / EC: Use busy polling mode when GPE is not enabled

When GPE is not enabled, it is not efficient to use the wait polling mode
as it introduces an unexpected scheduler delay.
So before the GPE handler is installed, this patch uses busy polling mode
for all EC(s) and the logic can be applied to non boot EC(s) during the
suspend/resume process.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=191561
Tested-by: Jakobus Schurz <jakobus.schurz@gmail.com>
Tested-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name ACPI-EC-Use-busy-polling-mode-when-GPE-is-not-enable.patch

Kbuild.include: addtree: Remove quotes before matching path

systemtap currently fails to build modules when the kernel source and
object trees are separate.

systemtap adds something like -I"/usr/share/systemtap/runtime" to
EXTRA_CFLAGS, and addtree should not adjust this as it's specifying an
absolute directory.  But since make has no understanding of shell
quoting, it does anyway.

For a long time this didn't matter, because addtree would still emit
the original -I option after the adjusted one.  However, commit
db547ef19064 ("Kbuild: don't add obj tree in additional includes")
changed it to remove the original -I option.

Remove quotes (both double and single) before matching against the
excluded patterns.

References: https://bugs.debian.org/856474
Reported-by: Jack Henschel <jackdev@mailbox.org>
Reported-by: Ritesh Raj Sarraf <rrs@debian.org>
Fixes: db547ef19064 ("Kbuild: don't add obj tree in additional includes")
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-include-addtree-remove-quotes-before-matching-path.patch

dvb-usb: Don't use stack for reset either

Commit 43fab9793c1f ("[media] dvb-usb: don't use stack for firmware
load") introduced a heap buffer for the firmware writes, but we need
to do the same for the register writes to reset the DVB device's
processor.

Cc: stable@vger.kernel.org # 4.9+
Fixes: 43fab9793c1f ("[media] dvb-usb: don't use stack for firmware load")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name media-dvb-usb-don-t-use-stack-for-reset-either.patch

dvb-usb: don't use stack for firmware load

As reported by Marc Duponcheel <marc@offline.be>, firmware load on
dvb-usb is using the stack, with is not allowed anymore on default
Kernel configurations:

[ 1025.958836] dvb-usb: found a 'WideView WT-220U PenType Receiver (based on ZL353)' in cold state, will try to load a firmware
[ 1025.958853] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw'
[ 1025.958855] dvb-usb: could not stop the USB controller CPU.
[ 1025.958856] dvb-usb: error while transferring firmware (transferred size: -11, block size: 3)
[ 1025.958856] dvb-usb: firmware download failed at 8 with -22
[ 1025.958867] usbcore: registered new interface driver dvb_usb_dtt200u

[    2.789902] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw'
[    2.789905] ------------[ cut here ]------------
[    2.789911] WARNING: CPU: 3 PID: 2196 at drivers/usb/core/hcd.c:1584 usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
[    2.789912] transfer buffer not dma capable
[    2.789912] Modules linked in: btusb dvb_usb_dtt200u(+) dvb_usb_af9035(+) btrtl btbcm dvb_usb dvb_usb_v2 btintel dvb_core bluetooth rc_core rfkill x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd drm_kms_helper syscopyarea sysfillrect pcspkr i2c_i801 sysimgblt fb_sys_fops drm i2c_smbus i2c_core r8169 lpc_ich mfd_core mii thermal fan rtc_cmos video button acpi_cpufreq processor snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd crc32c_intel ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd usbcore usb_common dm_mirror dm_region_hash dm_log dm_mod
[    2.789936] CPU: 3 PID: 2196 Comm: systemd-udevd Not tainted 4.9.0-gentoo #1
[    2.789937] Hardware name: ASUS All Series/H81I-PLUS, BIOS 0401 07/23/2013
[    2.789938]  ffffc9000339b690 ffffffff812bd397 ffffc9000339b6e0 0000000000000000
[    2.789939]  ffffc9000339b6d0 ffffffff81055c86 000006300339b6a0 ffff880116c0c000
[    2.789941]  0000000000000000 0000000000000000 0000000000000001 ffff880116c08000
[    2.789942] Call Trace:
[    2.789945]  [<ffffffff812bd397>] dump_stack+0x4d/0x66
[    2.789947]  [<ffffffff81055c86>] __warn+0xc6/0xe0
[    2.789948]  [<ffffffff81055cea>] warn_slowpath_fmt+0x4a/0x50
[    2.789952]  [<ffffffffa006d460>] usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
[    2.789954]  [<ffffffff814ed5a8>] ? io_schedule_timeout+0xd8/0x110
[    2.789956]  [<ffffffffa006e09c>] usb_hcd_submit_urb+0x9c/0x980 [usbcore]
[    2.789958]  [<ffffffff812d0ebf>] ? copy_page_to_iter+0x14f/0x2b0
[    2.789960]  [<ffffffff81126818>] ? pagecache_get_page+0x28/0x240
[    2.789962]  [<ffffffff8118c2a0>] ? touch_atime+0x20/0xa0
[    2.789964]  [<ffffffffa006f7c4>] usb_submit_urb+0x2c4/0x520 [usbcore]
[    2.789967]  [<ffffffffa006feca>] usb_start_wait_urb+0x5a/0xe0 [usbcore]
[    2.789969]  [<ffffffffa007000c>] usb_control_msg+0xbc/0xf0 [usbcore]
[    2.789970]  [<ffffffffa067903d>] usb_cypress_writemem+0x3d/0x40 [dvb_usb]
[    2.789972]  [<ffffffffa06791cf>] usb_cypress_load_firmware+0x4f/0x130 [dvb_usb]
[    2.789973]  [<ffffffff8109dbbe>] ? console_unlock+0x2fe/0x5d0
[    2.789974]  [<ffffffff8109e10c>] ? vprintk_emit+0x27c/0x410
[    2.789975]  [<ffffffff8109e40a>] ? vprintk_default+0x1a/0x20
[    2.789976]  [<ffffffff81124d76>] ? printk+0x43/0x4b
[    2.789977]  [<ffffffffa0679310>] dvb_usb_download_firmware+0x60/0xd0 [dvb_usb]
[    2.789979]  [<ffffffffa0679898>] dvb_usb_device_init+0x3d8/0x610 [dvb_usb]
[    2.789981]  [<ffffffffa069e302>] dtt200u_usb_probe+0x92/0xd0 [dvb_usb_dtt200u]
[    2.789984]  [<ffffffffa007420c>] usb_probe_interface+0xfc/0x270 [usbcore]
[    2.789985]  [<ffffffff8138bf95>] driver_probe_device+0x215/0x2d0
[    2.789986]  [<ffffffff8138c0e6>] __driver_attach+0x96/0xa0
[    2.789987]  [<ffffffff8138c050>] ? driver_probe_device+0x2d0/0x2d0
[    2.789988]  [<ffffffff81389ffb>] bus_for_each_dev+0x5b/0x90
[    2.789989]  [<ffffffff8138b7b9>] driver_attach+0x19/0x20
[    2.789990]  [<ffffffff8138b33c>] bus_add_driver+0x11c/0x220
[    2.789991]  [<ffffffff8138c91b>] driver_register+0x5b/0xd0
[    2.789994]  [<ffffffffa0072f6c>] usb_register_driver+0x7c/0x130 [usbcore]
[    2.789994]  [<ffffffffa06a5000>] ? 0xffffffffa06a5000
[    2.789996]  [<ffffffffa06a501e>] dtt200u_usb_driver_init+0x1e/0x20 [dvb_usb_dtt200u]
[    2.789997]  [<ffffffff81000408>] do_one_initcall+0x38/0x140
[    2.789998]  [<ffffffff8116001c>] ? __vunmap+0x7c/0xc0
[    2.789999]  [<ffffffff81124fb0>] ? do_init_module+0x22/0x1d2
[    2.790000]  [<ffffffff81124fe8>] do_init_module+0x5a/0x1d2
[    2.790002]  [<ffffffff810c96b1>] load_module+0x1e11/0x2580
[    2.790003]  [<ffffffff810c68b0>] ? show_taint+0x30/0x30
[    2.790004]  [<ffffffff81177250>] ? kernel_read_file+0x100/0x190
[    2.790005]  [<ffffffff810c9ffa>] SyS_finit_module+0xba/0xc0
[    2.790007]  [<ffffffff814f13e0>] entry_SYSCALL_64_fastpath+0x13/0x94
[    2.790008] ---[ end trace c78a74e78baec6fc ]---

So, allocate the structure dynamically.

Cc: stable@vger.kernel.org # Kernel 4.9+
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
[bwh: Backported to 4.9: adjust context]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name media-dvb-usb-don-t-use-stack-for-firmware-load.patch

dvb-usb-dibusb-mc-common: Add MODULE_LICENSE

dvb-usb-dibusb-mc-common is licensed under GPLv2, and if we don't say
so then it won't even load since it needs a GPL-only symbol.

Reported-by: Dominique Dumont <dod@debian.org>
References: https://bugs.debian.org/853110
Cc: stable@vger.kernel.org # 4.9+
Fixes: e91455a1495a ("[media] dvb-usb: split out common parts of dibusb")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name media-dvb-usb-dibusb-mc-common-add-module_license.patch

net: ipv6: check route protocol when deleting routes

The protocol field is checked when deleting IPv4 routes, but ignored for
IPv6, which causes problems with routing daemons accidentally deleting
externally set routes (observed by multiple bird6 users).

This can be verified using `ip -6 route del <prefix> proto something`.

Signed-off-by: Mantas Mikulėnas <grawity@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name net-ipv6-check-route-protocol-when-deleting-routes.patch

nbd: fix 64-bit division

We have this:

ERROR: "__aeabi_ldivmod" [drivers/block/nbd.ko] undefined!
ERROR: "__divdi3" [drivers/block/nbd.ko] undefined!
nbd.c:(.text+0x247c72): undefined reference to `__divdi3'

due to a recent commit, that did 64-bit division. Use the proper
divider function so that 32-bit compiles don't break.

Fixes: ef77b515243b ("nbd: use loff_t for blocksize and nbd_set_size args")
Signed-off-by: Jens Axboe <axboe@fb.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name nbd-fix-64-bit-division.patch

ath9k: fix NULL pointer dereference

relay_open() may return NULL, check the return value to avoid the crash.

BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
IP: [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
PGD 41cf28067 PUD 41be92067 PMD 0
Oops: 0000 [#1] SMP
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6+ #35
Hardware name: Hewlett-Packard h8-1080t/2A86, BIOS 6.15    07/04/2011
task: ffffffff81e0c4c0 task.stack: ffffffff81e00000
RIP: 0010:[<ffffffffa01a95c5>] [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
RSP: 0018:ffff88041f203ca0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000059f RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffffffff81f0ca98
RBP: ffff88041f203dc8 R08: ffffffffffffffff R09: 00000000000000ff
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffffffff81f0ca98 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000040 CR3: 000000041b6ec000 CR4: 00000000000006f0
Stack:
0000000000000363 00000000000003f3 00000000000003f3 00000000000001f9
000000000000049a 0000000001252c04 ffff88041f203e44 ffff880417b4bfd0
0000000000000008 ffff88041785b9c0 0000000000000002 ffff88041613dc60

Call Trace:
<IRQ>
[<ffffffffa01b6441>] ath9k_tasklet+0x1b1/0x220 [ath9k]
[<ffffffff8105d8dd>] tasklet_action+0x4d/0xf0
[<ffffffff8105dde2>] __do_softirq+0x92/0x2a0

Reported-by: Devin Tuchsen <devin.tuchsen@gmail.com>
Tested-by: Devin Tuchsen <devin.tuchsen@gmail.com>
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name ath9k-fix-null-pointer-dereference.patch

nbd: use loff_t for blocksize and nbd_set_size args

If we have large devices (say like the 40t drive I was trying to test with) we
will end up overflowing the int arguments to nbd_set_size and not get the right
size for our device.  Fix this by using loff_t everywhere so I don't have to
think about this again.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
[bwh: Backported to 4.9: adjust context]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name nbd-use-loff_t-for-blocksize-and-nbd_set_size-args.patch

Partially revert "usb: Kconfig: using select for USB_COMMON dependency"

This reverts commit cb9c1cfc86926d0e86d19c8e34f6c23458cd3478 for
USB_LED_TRIG.  This config symbol has bool type and enables extra code
in usb_common itself, not a separate driver.  Enabling it should not
force usb_common to be built-in!

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name partially-revert-usb-kconfig-using-select-for-usb_co.patch

mm: memcontrol: use special workqueue for creating per-memcg caches

Creating a lot of cgroups at the same time might stall all worker
threads with kmem cache creation works, because kmem cache creation is
done with the slab_mutex held. The problem was amplified by commits
801faf0db894 ("mm/slab: lockless decision to grow cache") in case of
SLAB and 81ae6d03952c ("mm/slub.c: replace kick_all_cpus_sync() with
synchronize_sched() in kmem_cache_shrink()") in case of SLUB, which
increased the maximal time the slab_mutex can be held.

To prevent that from happening, let's use a special ordered single
threaded workqueue for kmem cache creation. This shouldn't introduce any
functional changes regarding how kmem caches are created, as the work
function holds the global slab_mutex during its whole runtime anyway,
making it impossible to run more than one work at a time. By using a
single threaded workqueue, we just avoid creating a thread per each
work. Ordering is required to avoid a situation when a cgroup's work is
put off indefinitely because there are other cgroups to serve, in other
words to guarantee fairness.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=172981
Signed-off-by: Vladimir Davydov <vdavydov.dev@gmail.com>
Reported-by: Doug Smythies <dsmythies@telus.net>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Pekka Enberg <penberg@kernel.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name mm-memcontrol-use-special-workqueue-for-creating-per-memcg-caches.patch

Trouble mounting metadata_csum ext4 filesystems with v4.7.x after c9274d891869880648c4ee9365df3ecc7ba2e285: not enough inode bytes checksummed?

[cc Ted and the ext4 list]

On Mon, Sep 19, 2016 at 03:19:03PM +0100, Nix wrote:
> So I ran into spurious metadata corruption warnings in v4.7.2 due to the
> problem fixed by c9274d8. I applied an early version of the fix,
> rebooted, and oh dear root filesystem mount failure with invalid
> checksum errors.
>
> The problem persists in v4.7.4, as seen here in qemu emulation on a raw
> image dd'ed directly from the thing that won't boot, with a couple of
> printk()s:
>
> # mount /dev/vda /new-root/
> [    8.124692] EXT4-fs (vda): couldn't mount as ext3 due to feature incompatibilities
> [    8.126977] EXT4-fs (vda): couldn't mount as ext2 due to feature incompatibilities
> [    9.017980] Inode size 256 > good old size 128; fits in inode: 0
> [    8.134897] inode 8: provided: 5c50l; calculated: 36e1i
> [    8.135098] EXT4-fs error (device vda): ext4_iget:4479: inode #8: comm mount: checksum invalid
> [    8.138992] EXT4-fs (vda): no journal found
> [    8.165744] UDF-fs: warning (device vda): udf_fill_super: No partition found (2)
> mount: mounting /dev/vda on /new-root/ failed: Invalid argument
>
> I added a bit of printking to show the failure of the journal inode
> checksum to pass muster. e2fsck (from e2fsprogs 1.43.1-14) is quite
> happy with this filesystem. Reverting c9274d8 makes everything happy
> again (well, it does bring the original bug back, which is a rather
> serious one, but other than that...):
>
> [    9.823032] EXT4-fs (vda): couldn't mount as ext3 due to feature incompatibilities
> [    9.824647] EXT4-fs (vda): couldn't mount as ext2 due to feature incompatibilities
> [    9.832593] inode 8: provided: 5c50l; calculated: 5c50i
> [    9.839253] inode 2: provided: d6ea92e9l; calculated: d6ea92e9i
> [    9.846947] EXT4-fs (vda): mounted filesystem with ordered data mode. Opts: (null)
>
> So c9274d8 is clearly messing up the calculation of the checksum.
>
> The problem becomes more evident if we add more printk()s to the old
> code, so we can see what region is being checksummed:
>
> # mount /dev/vda /new-root
> [    6.827297] inode 8: unadjusted csum of 256 bytes with seed a5df92a7: 449a5c50
> [    6.827596] adjusted csum: 5c50
> [    6.835993] inode 2: unadjusted csum of 256 bytes with seed 759c6c33: d6ea92e9
> [    6.836173] adjusted csum: d6ea92e9
> [    6.844801] EXT4-fs (vda): mounted filesystem with ordered data mode. Opts:
>
> and the new:
>
> [   11.098013] inode 8: csum of first 124 bytes with seed a5df92a7: f375b663
> [   11.098205] inode 8: added csum of 2 dummy_csum bytes with seed a5df92a7: 20cfebcb
> [   11.098420] inode 8: added csum of 2 bytes from offset 126 -- 128 to existing: d79e7432
> [   11.098646] inode 8: > GOOD_OLD_INODE_SIZE; added csum of 2 bytes from 128 -- 130 to existing: d10936e1
> [   11.098890] 8: adjusted csum: 36e1
> [   11.099133] EXT4-fs error (device vda): ext4_iget:4483: inode #8: comm mount: checksum invalid
>
> We are not checksumming enough bytes! We used to checksum the entire
> 256-byte inode: now, we checksum only 130 bytes of it, which isn't even
> enough to cover the 28-byte extra_isize on this filesystem and is more
> or less guaranteed to give the wrong answer. I'd fix the problem, but I
> frankly can't see how the new code is meant to be equivalent to the old
> code in any sense -- most particularly what the stuff around dummy_csum
> is meant to do -- so I thought it better to let the people who wrote it
> fix it :)

Sh*t, I missed this during the review.  So your filesystem image (thank
you!) had this to say:

debugfs> stats
Inode size:               256
debugfs> stat <8>
Size of extra inode fields: 0

Basically, a 128-byte inode inside a filesystem that allocated 256 bytes
for each inode.  As you point out, the old code would checksum the entire
allocated space, whether or not the inode core used it.  Obviously, you
want this since inline extended attributes live in that space:

csum = ext4_chksum(sbi, ei->i_csum_seed, (__u8 *)raw,
   EXT4_INODE_SIZE(inode->i_sb));

The new code, on the other hand, carefully checksums around the
i_checksum fields and only bothers to checksum the space between the end
of i_checksum_hi and the end of the allocated space if the inode core is
big enough to store i_checksum_hi.  Since we allocated 256 bytes for
each inode, we checksum the first two bytes after byte 128
(EXT4_GOOD_OLD_INODE_SIZE), but then we see that i_extra_size == 0 so we
never bother to checksum anything after that.  This is of course wrong
since we no longer checksum the xattr space and we've deviated from the
pre-4.7.4 (documented) on-disk format.

*FORTUNATELY* since the root inode fails the read verifier, the file (in
this case the root dir) can't be modified and therefore nothing has been
corrupted.  Especially fortunate for you, the fs won't mount, reducing
the chances that any serious damage has occurred.

I /think/ the fix in this case is to hoist the last ext4_chksum call
out of the EXT4_FITS_IN_INODE blob:

if (EXT4_INODE_SIZE(inode->i_sb) > EXT4_GOOD_OLD_INODE_SIZE) {
offset = offsetof(struct ext4_inode, i_checksum_hi);
csum = ext4_chksum(sbi, csum, (__u8 *)raw +
   EXT4_GOOD_OLD_INODE_SIZE,
   offset - EXT4_GOOD_OLD_INODE_SIZE);
if (EXT4_FITS_IN_INODE(raw, ei, i_checksum_hi)) {
csum = ext4_chksum(sbi, csum, (__u8 *)&dummy_csum,
   csum_size);
offset += csum_size;
}
csum = ext4_chksum(sbi, csum, (__u8 *)raw + offset,
   EXT4_INODE_SIZE(inode->i_sb) - offset);
}

Can you give that a try?

> tune2fs output for this filesystem, particularly the extra_isize and
> inode size fields are likely relevant:
>
> tune2fs 1.43.1 (08-Jun-2016)
> Filesystem volume name:   root
> Last mounted on:          /
> Filesystem UUID:          6c0f7fa7-d6c2-4054-bff3-3a878460bdc7
> Filesystem magic number:  0xEF53
> Filesystem revision #:    1 (dynamic)
> Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
> Filesystem flags:         signed_directory_hash
> Default mount options:    (none)
> Filesystem state:         clean
> Errors behavior:          Continue
> Filesystem OS type:       Linux
> Inode count:              65536
> Block count:              262144
> Reserved block count:     13107
> Free blocks:              227009
> Free inodes:              59499
> First block:              0
> Block size:               4096
> Fragment size:            4096
> Group descriptor size:    64
> Reserved GDT blocks:      63
> Blocks per group:         32768
> Fragments per group:      32768
> Inodes per group:         8192
> Inode blocks per group:   512
> RAID stripe width:        16
> Flex block group size:    64
> Filesystem created:       Tue May 26 21:28:46 2009
> Last mount time:          Sun Sep 18 23:34:41 2016
> Last write time:          Mon Sep 19 13:51:59 2016
> Mount count:              0
> Maximum mount count:      36
> Last checked:             Mon Sep 19 13:51:59 2016
> Check interval:           15552000 (6 months)
> Next check after:         Sat Mar 18 12:51:59 2017
> Lifetime writes:          16 GB
> Reserved blocks uid:      0 (user root)
> Reserved blocks gid:      0 (group root)
> First inode:              11
> Inode size:               256
> Required extra isize:     28
> Desired extra isize:      28
> Journal inode:            8
> Default directory hash:   half_md4
> Directory Hash Seed:      f1da2da0-057e-4ba0-a021-3d56db5b24ab
> Journal backup:           inode blocks
> Checksum type:            crc32c
> Checksum:                 0x92acf115
>
> This is an old, upgraded fs from before the days of checksums, but even
> so I'm surprised that with a 256-byte inode and no xattrs in use,
> EXT4_FITS_IN_INODE is false. Maybe the extra_isize isn't big enough?

It's zero, so yes. :)

> An lzipped e2image of the problematic filesystem is available from
> <http://www.esperi.org.uk/~nix/temporary/csum-corruption.img.lz>:
> I have verified that the problem recurs with this image.
>
> I can also replicate the problem in literally seconds if you need more
> debugging output.
>
>
> ... The mystery is why this isn't going wrong anywhere else: I have
> metadata_csum working on every fs on a bunch of other ext4-using
> systems, and indeed on every filesystem on this machine as well, as long
> as c9274d8 is not applied. Many of them are similarly upgraded pre-csum
> fses with the same inode size and extra_isize, but they work...

Hard to say, but this bug only affects inodes with 0 < i_extra_size <= 4
i.e. 128 < inode-core-size <= 130.  Maybe an old ext3 fs that was
created with 256 bytes per inode but inode-core-size of 128?

Uck.  Sorry about this mess.

--D

[bwh: Converted to a patch]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name ext4-fix-bug-838544.patch

kbuild: Do not use hyphen in exported variable name

This definition in Makefile.dtbinst:

    export dtbinst-root ?= $(obj)

should define and export dtbinst-root when handling the root dts
directory, and do nothing in the subdirectories.  However, the
variable does not reliably get exported to the environment, perhaps
because its name contains a hyphen.

Rename the variable to dtbinst_root.

References: https://bugs.debian.org/833561
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-do-not-use-hyphen-in-exported-variable-name.patch

fs: Add MODULE_SOFTDEP declarations for hard-coded crypto drivers

This helps initramfs builders and other tools to find the full
dependencies of a module.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name fs-add-module_softdep-declarations-for-hard-coded-cr.patch

phy/marvell: disable 4-port phys

The Marvell PHY was originally disabled because it can cause networking
failures on some systems. According to Lennert Buytenhek this is because some
of the variants added did not share the same register layout. Since the known
cases are all 4-ports disable those variants (indicated by a 4 in the
penultimate position of the model name) until they can be audited for
correctness.

[bwh: Also #if-out the init functions for these PHYs to avoid
 compiler warnings]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name disable-some-marvell-phys.patch

kbuild: Use -nostdinc in compile tests

Debian's gcc 4.8 pre-includes <stdc-predef.h> by default, which in
turn includes <bits/predefs.h>.  This fails when building a 64-bit
kernel and only 32-bit C library headers installed.

The -nostdinc option disables this, though it isn't explicitly
documented.  This option is already used when actually building
the kernel.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-use-nostdinc-in-compile-tests.patch

ARM: orion5x: fix Makefile for linkstation-lschl.dtb

The rename of orion5x-lschl.dts needs to be reflected in the Makefile:

make[3]: *** No rule to make target 'arch/arm/boot/dts/orion5x-lschl.dtb', needed by '__build'.

Fixes: 6cfd3cd8d836 ("ARM: dts: orion5x-lschl: More consistent naming on linkstation series")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name ARM-orion5x-fix-Makefile-for-linkstation-lschl.dtb.patch

ARM: dts: orion5x-lschl: More consistent naming on linkstation series

DTS files, which includes orion5x-linkstation.dtsi, are named:
  orion5x-linkstation-*.dts

So we rename the file below:
  arch/arm/boot/dts/orion5x-lschl.dts
to the new name:
  arch/arm/boot/dts/orion5x-linkstation-lschl.dts

Because DTS conversion of this device was just introduced in 4.9, Debian
is still using legacy device support, other distros are the same,
so here we won't expect any impact actually.

Fixes: f94f268979a2 ("ARM: dts: orion5x: convert ls-chl to FDT")
Cc: Ashley Hughes <ashley.hughes@blueyonder.co.uk>
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name ARM-dts-orion5x-lschl-More-consistent-naming-on-link.patch

ARM: dts: orion5x-lschl: Fix model name

Model name should be consistent with legacy device file, so that user
can migrate their system from legacy device support to device-tree
safely.

Legacy device file is currently removed, but it can be found on 4.8
or previous version of linux:
  arch/arm/mach-orion5x/ls-chl-setup.c

Fixes: f94f268979a2 ("ARM: dts: orion5x: convert ls-chl to FDT")
Cc: Ashley Hughes <ashley.hughes@blueyonder.co.uk>
Signed-off-by: Roger Shimizu <rogershimizu@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name ARM-dts-orion5x-lschl-Fix-model-name.patch

ARM64: dts: meson-gx: Add firmware reserved memory zones

The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds these reserved zones.

Without such reserved memory zones, running the following stress command :
$ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
multiple times:

Could lead to the following kernel crashes :
[   46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
...
[   47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
...
Instead of the OOM killer.

Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
[khilman: added Fixes tag, added _reserved and unit addresses]
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
[bwh: Backported to 4.9: adjust filename]

Gbp-Pq: Topic features/arm64
Gbp-Pq: Name dts-meson-gx-add-firmware-reserved-memory-zone.patch

ARM: dts: orion5x: convert ls-chl to FDT

This patch converts my orion5x ls-chl Linkstation device to device tree.

[gregory.clement@free-electrons.com: fix title, add back the commit log,
move the removal of the platform in an other patch]
Signed-off-by: Ashley Hughes <ashley.hughes@blueyonder.co.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name ARM-dts-orion5x-convert-ls-chl-to-FDT.patch

ARM: dts: turris-omnia: add support for ethernet switch

The Turris Omnia features a Marvell MV88E6176 ethernet switch. Add it to
the dts.

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-turris-omnia-add-support-for-ethernet-switch.patch

ARM: dts: add support for Turris Omnia

This machine is an open hardware router by cz.nic driven by a
Marvell Armada 385.

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-add-support-for-turris-omnia.patch

x86: Make x32 syscall support conditional on a kernel parameter

Enabling x32 in the standard amd64 kernel would increase its attack
surface while provide no benefit to the vast majority of its users.
No-one seems interested in regularly checking for vulnerabilities
specific to x32 (at least no-one with a white hat).

Still, adding another flavour just to turn on x32 seems wasteful.  And
the only differences on syscall entry are two instructions (mask out
the x32 flag and compare the syscall number).

So pad the standard comparison with a nop and add a kernel parameter
"syscall.x32" which controls whether this is replaced with the x32
version at boot time.  Add a Kconfig parameter to set the default.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-make-x32-syscall-support-conditional.patch

x86: memtest: WARN if bad RAM found

Since this is not a particularly thorough test, if we find any bad
bits of RAM then there is a fair chance that there are other bad bits
we fail to detect.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-memtest-WARN-if-bad-RAM-found.patch

MIPS: octeon: Add support for the UBNT E200 board

Add support for the UBNT E200 board (EdgeRouter/EdgeRouter Pro 8 port).

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
[bwh: Forward-ported to 3.17: adjust context]

Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-octeon-Add-support-for-the-UBNT-E200-board.patch

MIPS: Loongson 3: Add Loongson LS3A RS780E 1-way machine definition

Add a Loongson LS3A RS780E 1-way machine definition, which only differs
from other Loongson 3 based machines by the UART base clock speed.

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
[bwh: Forward-ported to 4.2]

Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-Loongson-3-Add-Loongson-LS3A-RS780E-1-way-machi.patch

MIPS: increase MAX_PHYSMEM_BITS on Loongson 3 only

Commit c4617318 broke Loongson-2 support and maybe even more by increasing
the value of MAX_PHYSMEM_BITS. At it is currently only needed on
Loongson-3, define it conditionally.

Note: this should be replace by upstream fix when available.

Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-increase-MAX-PHYSMEM-BITS-on-Loongson-3-only.patch

rtc: tegra: Implement clock handling

Accessing the registers of the RTC block on Tegra requires the module
clock to be enabled. This only works because the RTC module clock will
be enabled by default during early boot. However, because the clock is
unused, the CCF will disable it at late_init time. This causes the RTC
to become unusable afterwards. This can easily be reproduced by trying
to use the RTC:

$ hwclock --rtc /dev/rtc1

This will hang the system. I ran into this by following up on a report
by Martin Michlmayr that reboot wasn't working on Tegra210 systems. It
turns out that the rtc-tegra driver's ->shutdown() implementation will
hang the CPU, because of the disabled clock, before the system can be
rebooted.

What confused me for a while is that the same driver is used on prior
Tegra generations where the hang can not be observed. However, as Peter
De Schrijver pointed out, this is because on 32-bit Tegra chips the RTC
clock is enabled by the tegra20_timer.c clocksource driver, which uses
the RTC to provide a persistent clock. This code is never enabled on
64-bit Tegra because the persistent clock infrastructure does not exist
on 64-bit ARM.

The proper fix for this is to add proper clock handling to the RTC
driver in order to ensure that the clock is enabled when the driver
requires it. All device trees contain the clock already, therefore
no additional changes are required.

Reported-by: Martin Michlmayr <tbm@cyrius.com>
Acked-By Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
[bwh: Backported to 4.9: adjust context]

Gbp-Pq: Topic bugfix/arm64
Gbp-Pq: Name rtc-tegra-implement-clock-handling.patch

ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419

The old board code for the TS419 assigns MPP pins 15 and 16 as SATA
activity signals (and none as SATA presence signals).  Currently the
device tree assigns the SoC's default pinmux groups for SATA, which
conflict with the second Ethernet port.

Reported-by: gmbh@gazeta.pl
Tested-by: gmbh@gazeta.pl
References: https://bugs.debian.org/855017
Cc: stable@vger.kernel.org # 3.15+
Fixes: 934b524b3f49 ("ARM: Kirkwood: Add DT description of QNAP 419")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-dts-kirkwood-fix-sata-pinmux-ing-for-ts419.patch

x86/xen: Fix APIC id mismatch warning on Intel

This patch fixes the following warning message seen when booting the
kernel as Dom0 with Xen on Intel machines.

[0.003000] [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 0 APIC: 1]

The code generating the warning in validate_apic_and_package_id() matches
cpu_data(cpu).apicid (initialized in init_intel()->
detect_extended_topology() using cpuid) against the apicid returned from
xen_apic_read(). Now, xen_apic_read() makes a hypercall to retrieve apicid
for the boot  cpu but returns 0 otherwise. Hence the warning gets thrown
for all but the boot cpu.

The idea behind xen_apic_read() returning 0 for apicid is that the
guests (even Dom0) should not need to know what physical processor their
vcpus are running on. This is because we currently  do not have topology
information in Xen and also because xen allows more vcpus than physical
processors. However, boot cpu's apicid is required for loading
xen-acpi-processor driver on AMD machines. Look at following patch for
details:

commit 558daa289a40 ("xen/apic: Return the APIC ID (and version) for CPU
0.")

So to get rid of the warning, this patch modifies
xen_cpu_present_to_apicid() to return cpu_data(cpu).apicid instead of
calling xen_apic_read().

The warning is not seen on AMD machines because init_amd() populates
cpu_data(cpu).apicid by calling hard_smp_processor_id()->xen_apic_read()
as opposed to using apicid from cpuid as is done on Intel machines.

Signed-off-by: Mohit Gambhir <mohit.gambhir@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-xen-fix-apic-id-mismatch-warning-on-intel.patch

platform/x86: acer-wmi: setup accelerometer when machine has appropriate notify event

The accelerometer event relies on the ACERWMID_EVENT_GUID notify.
So, this patch changes the codes to setup accelerometer input device
when detected ACERWMID_EVENT_GUID. It avoids that the accel input
device created on every Acer machines.

In addition, patch adds a clearly parsing logic of accelerometer hid
to acer_wmi_get_handle_cb callback function. It is positive matching
the "SENR" name with "BST0001" device to avoid non-supported hardware.

Reported-by: Bjørn Mork <bjorn@mork.no>
Cc: Darren Hart <dvhart@infradead.org>
Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
[andy: slightly massage commit message]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-acer-wmi-setup-accelerometer-when-machi.patch

ASoC: Intel: select DW_DMAC_CORE since it's mandatory

Select DW_DMAC_CORE like the rest of glue drivers do, e.g.
drivers/dma/dw/Kconfig.

While here group selectors under SND_SOC_INTEL_HASWELL and
SND_SOC_INTEL_BAYTRAIL.

Make platforms, which are using a common SST firmware driver, to be
dependent on DMADEVICES.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name asoc-intel-select-dw_dmac_core-since-it-s-mandatory.patch

Don't WARN about expected W+X pages on Xen

Currently Xen PV domains (or at least dom0) on amd64 tend to have a
large number of low kernel pages with W+X permissions.  It's not
obvious how to fix this, and we're not going to get any new
information by WARNing about this, but we do still want to hear about
other W+X cases.  So add a condition to the WARN_ON.

Gbp-Pq: Topic debian
Gbp-Pq: Name amd64-don-t-warn-about-expected-w+x-pages-on-xen.patch

fanotify: Taint on use of FANOTIFY_ACCESS_PERMISSIONS

Various free and proprietary AV products use this feature and users
apparently want it.  But punting access checks to userland seems like
an easy way to deadlock the system, and there will be nothing we can
do about that.  So warn and taint the kernel if this feature is
actually used.

Gbp-Pq: Topic debian
Gbp-Pq: Name fanotify-taint-on-use-of-fanotify_access_permissions.patch

fjes: Disable auto-loading

fjes matches a generic ACPI device ID, and relies on its probe
function to distinguish whether that really corresponds to a supported
device.  Very few system will need the driver and it wastes memory on
all the other systems where the same device ID appears, so disable
auto-loading.

Gbp-Pq: Topic debian
Gbp-Pq: Name fjes-disable-autoload.patch

viafb: Autoload on OLPC XO 1.5 only

It appears that viafb won't work automatically on all the boards for
which it has a PCI device ID match.  Currently, it is blacklisted by
udev along with most other framebuffer drivers, so this doesn't matter
much.

However, this driver is required for console support on the XO 1.5.
We need to allow it to be autoloaded on this model only, and then
un-blacklist it in udev.

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name viafb-autoload-on-olpc-xo1.5-only.patch

snd-pcsp: Disable autoload

There are two drivers claiming the platform:pcspkr device:
- pcspkr creates an input(!) device that can only beep
- snd-pcsp creates an equivalent input device plus a PCM device that can
  play barely recognisable renditions of sampled sound

snd-pcsp is blacklisted by the alsa-base package, but not everyone
installs that.  On PCs where no sound is wanted at all, both drivers
will still be loaded and one or other will complain that it couldn't
claim the relevant I/O range.

In case anyone finds snd-pcsp useful, we continue to build it.  But
remove the alias, to ensure it's not loaded where it's not wanted.

Gbp-Pq: Topic debian
Gbp-Pq: Name snd-pcsp-disable-autoload.patch

cdc_ncm,cdc_mbim: Use NCM by default

Devices that support both NCM and MBIM modes should be kept in NCM
mode unless there is userland support for MBIM.

Set the default value of cdc_ncm.prefer_mbim to false and leave it to
userland (modem-manager) to override this with a modprobe.conf file
once it's ready to speak MBIM.

Gbp-Pq: Topic debian
Gbp-Pq: Name cdc_ncm-cdc_mbim-use-ncm-by-default.patch

security,perf: Allow further restriction of perf_event_open

When kernel.perf_event_open is set to 3 (or greater), disallow all
access to performance events by users without CAP_SYS_ADMIN.
Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
makes this value the default.

This is based on a similar feature in grsecurity
(CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
the variable read-only.  It also allows enabling further restriction
at run-time regardless of whether the default is changed.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name security-perf-allow-further-restriction-of-perf_event_open.patch

add sysctl to disallow unprivileged CLONE_NEWUSER by default

add sysctl to disallow unprivileged CLONE_NEWUSER by default

This is a short-term patch.  Unprivileged use of CLONE_NEWUSER
is certainly an intended feature of user namespaces.  However
for at least saucy we want to make sure that, if any security
issues are found, we have a fail-safe.

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
[bwh: Remove unneeded binary sysctl bits]

Gbp-Pq: Topic debian
Gbp-Pq: Name add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch

yama: Disable by default

Gbp-Pq: Topic debian
Gbp-Pq: Name yama-disable-by-default.patch

sched: Do not enable autogrouping by default

We want to provide the option of autogrouping but without enabling
it by default yet.

Gbp-Pq: Topic debian
Gbp-Pq: Name sched-autogroup-disabled.patch

fs: Enable link security restrictions by default

This reverts commit 561ec64ae67ef25cac8d72bb9c4bfc955edfd415
('VFS: don't do protected {sym,hard}links by default').

Gbp-Pq: Topic debian
Gbp-Pq: Name fs-enable-link-security-restrictions-by-default.patch

dccp: Disable auto-loading as mitigation against local exploits

We can mitigate the effect of vulnerabilities in obscure protocols by
preventing unprivileged users from loading the modules, so that they
are only exploitable on systems where the administrator has chosen to
load the protocol.

The 'dccp' protocol is not actively maintained or widely used.
Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name dccp-disable-auto-loading-as-mitigation-against-local-exploits.patch

decnet: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'decnet' protocol is unmaintained and of mostly historical
interest, and the user-space support package 'dnet-common' loads the
module explicitly.  Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name decnet-Disable-auto-loading-as-mitigation-against-lo.patch

rds: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'rds' protocol is one such protocol that has been found to be
vulnerable, and which was not present in the 'lenny' kernel.
Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name rds-Disable-auto-loading-as-mitigation-against-local.patch

af_802154: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'af_802154' (IEEE 802.15.4) protocol is not widely used, was
not present in the 'lenny' kernel, and seems to receive only sporadic
maintenance.  Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name af_802154-Disable-auto-loading-as-mitigation-against.patch

aufs4.9 standalone patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.9 standalone patch

Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-standalone.patch

aufs4.9 mmap patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.9 mmap patch

Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-mmap.patch

aufs4.9 base patch

Patch headers added by debian/patches/features/all/aufs4/gen-patch

aufs4.9 base patch

Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-base.patch

radeon: Firmware is required for DRM and KMS on R600 onward

radeon requires firmware/microcode for the GPU in all chips, but for
newer chips (apparently R600 'Evergreen' onward) it also expects
firmware for the memory controller and other sub-blocks.

radeon attempts to gracefully fall back and disable some features if
the firmware is not available, but becomes unstable - the framebuffer
and/or system memory may be corrupted, or the display may stay black.

Therefore, perform a basic check for the existence of
/lib/firmware/radeon when a device is probed, and abort if it is
missing, except for the pre-R600 case.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name radeon-firmware-is-required-for-drm-and-kms-on-r600-onward.patch

firmware: Remove redundant log messages from drivers

Now that firmware_class logs every success and failure consistently,
many other log messages can be removed from drivers.

This will probably need to be split up into multiple patches prior to
upstream submission.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name firmware-remove-redundant-log-messages-from-drivers.patch

firmware_class: Log every success and failure against given device

The hundreds of users of request_firmware() have nearly as many
different log formats for reporting failures.  They also have only the
vaguest hint as to what went wrong; only firmware_class really knows
that.  Therefore, add specific log messages for the failure modes that
aren't currently logged.

In case of a driver that tries multiple names, this may result in the
impression that it failed to initialise.  Therefore, also log successes.

This makes many error messages in drivers redundant, which will be
removed in later patches.

This does not cover the case where we fall back to a user-mode helper
(which is no longer enabled in Debian).

NOTE: hw-detect will depend on the "firmware: failed to load %s (%d)\n"
format to detect missing firmware.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name firmware_class-log-every-success-and-failure.patch

iwlwifi: Do not request unreleased firmware for IWL6000

The iwlwifi driver currently supports firmware API versions 4-6 for
these devices.  It will request the file for the latest supported
version and then fall back to earlier versions.  However, the latest
version that has actually been released is 4, so we expect the
requests for versions 6 and then 5 to fail.

The installer appears to report any failed request, and it is probably
not easy to detect that this particular failure is harmless.  So stop
requesting the unreleased firmware.

Gbp-Pq: Topic debian
Gbp-Pq: Name iwlwifi-do-not-request-unreleased-firmware.patch

af9005: Use request_firmware() to load register init script

Read the register init script from the Windows driver.  This is sick
but should avoid the potential copyright infringement in distributing
a version of the script which is directly derived from the driver.

Gbp-Pq: Topic features/all
Gbp-Pq: Name drivers-media-dvb-usb-af9005-request_firmware.patch

Install perf scripts non-executable

[bwh: Forward-ported to 3.12]

Gbp-Pq: Topic debian
Gbp-Pq: Name tools-perf-install.patch

Create manpages and binaries including the version

[bwh: Fix version insertion in perf man page cross-references and perf
man page title.  Install bash_completion script for perf with a
version-dependent name.  And do the same for trace.]

Gbp-Pq: Topic debian
Gbp-Pq: Name tools-perf-version.patch

modpost symbol prefix setting

[bwh: The original version of this was added by Bastian Blank.  The
upstream code includes <generated/autoconf.h> so that <linux/export.h>
can tell whether C symbols have an underscore prefix.  Since we build
modpost separately from the kernel, <generated/autoconf.h> won't exist.
However, no Debian Linux architecture uses the symbol prefix, so we
can simply omit it.]

Gbp-Pq: Topic debian
Gbp-Pq: Name modpost-symbol-prefix.patch

Kbuild: kconfig: Verbose version of --listnewconfig

If the KBUILD_VERBOSE environment variable is set to non-zero, show
the default values of new symbols and not just their names.

Based on work by Bastian Blank <waldi@debian.org> and
maximilian attems <max@stro.at>.  Simplified by Michal Marek
<mmarek@suse.cz>.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name Kbuild-kconfig-Verbose-version-of-listnewconfig.patch

powerpcspe-omit-uimage

Gbp-Pq: Topic debian
Gbp-Pq: Name powerpcspe-omit-uimage.patch

Fix uImage build

[bwh: This was added without a description, but I think it is dealing
with a similar issue to powerpcspe-omit-uimage.patch]

Gbp-Pq: Topic debian
Gbp-Pq: Name arch-sh4-fix-uimage-build.patch

Partially revert "MIPS: Add -Werror to arch/mips/Kbuild"

This reverts commit 66f9ba101f54bda63ab1db97f9e9e94763d0651b.

We really don't want to add -Werror anywhere.

Gbp-Pq: Topic debian
Gbp-Pq: Name mips-disable-werror.patch

Tweak gitignore for Debian pkg-kernel using git svn.

[bwh: Tweak further for pure git]

Gbp-Pq: Topic debian
Gbp-Pq: Name gitignore.patch

kbuild: Make the toolchain variables easily overwritable

Allow make variables to be overridden for each flavour by a file in
the build tree, .kernelvariables.

We currently use this for ARCH, KERNELRELEASE, CC, and in some cases
also CROSS_COMPILE, CFLAGS_KERNEL and CFLAGS_MODULE.

This file can only be read after we establish the build tree, and all
use of $(ARCH) needs to be moved after this.

Gbp-Pq: Topic debian
Gbp-Pq: Name kernelvariables.patch

Make mkcompile_h accept an alternate timestamp string

We want to include the Debian version in the utsname::version string
instead of a full timestamp string.  However, we still need to provide
a standard timestamp string for gen_initramfs_list.sh to make the
kernel image reproducible.

Make mkcompile_h use $KBUILD_BUILD_VERSION_TIMESTAMP in preference to
$KBUILD_BUILD_TIMESTAMP.

Gbp-Pq: Topic debian
Gbp-Pq: Name uname-version-timestamp.patch

Include package version along with kernel release in stack traces

For distribution binary packages we assume
$DISTRIBUTION_OFFICIAL_BUILD, $DISTRIBUTOR and $DISTRIBUTION_VERSION
are set.

Gbp-Pq: Topic debian
Gbp-Pq: Name version.patch

linux (4.9.18-1) unstable; urgency=medium

  * New upstream stable update:
    https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.17
    - net/mlx5e: Register/unregister vport representors on interface
      attach/detach
    - net/mlx5e: Do not reduce LRO WQE size when not using build_skb
    - net/mlx5e: Fix wrong CQE decompression
    - vxlan: correctly validate VXLAN ID against VXLAN_N_VID
    - vti6: return GRE_KEY for vti6
    - vxlan: don't allow overwrite of config src addr
    - ipv4: mask tos for input route
    - net sched actions: decrement module reference count after table flush.
    - l2tp: avoid use-after-free caused by l2tp_ip_backlog_recv
    - net: phy: Avoid deadlock during phy_error()
    - vxlan: lock RCU on TX path
    - geneve: lock RCU on TX path
    - tcp/dccp: block BH for SYN processing
    - net: bridge: allow IPv6 when multicast flood is disabled
    - net: don't call strlen() on the user buffer in packet_bind_spkt()
    - net: net_enable_timestamp() can be called from irq contexts
    - ipv6: orphan skbs in reassembly unit
    - dccp: Unlock sock before calling sk_free()
    - strparser: destroy workqueue on module exit
    - tcp: fix various issues for sockets morphing to listen state
    - net: fix socket refcounting in skb_complete_wifi_ack()
    - net: fix socket refcounting in skb_complete_tx_timestamp()
    - net/sched: act_skbmod: remove unneeded rcu_read_unlock in tcf_skbmod_dump
    - dccp: fix use-after-free in dccp_feat_activate_values
    - vrf: Fix use-after-free in vrf_xmit
    - net/tunnel: set inner protocol in network gro hooks
    - act_connmark: avoid crashing on malformed nlattrs with null parms
    - mpls: Send route delete notifications when router module is unloaded
    - mpls: Do not decrement alive counter for unregister events
    - ipv6: make ECMP route replacement less greedy
    - ipv6: avoid write to a possibly cloned skb
    - bridge: drop netfilter fake rtable unconditionally
    - dccp/tcp: fix routing redirect race
    - tun: fix premature POLLOUT notification on tun devices
    - dccp: fix memory leak during tear-down of unsuccessful connection request
    - bpf: Detect identical PTR_TO_MAP_VALUE_OR_NULL registers
    - bpf: fix state equivalence
    - bpf: fix regression on verifier pruning wrt map lookups
    - bpf: fix mark_reg_unknown_value for spilled regs on map value marking
    - dmaengine: iota: ioat_alloc_chan_resources should not perform sleeping
      allocations.
    - xen: do not re-use pirq number cached in pci device msi msg data
    - igb: Workaround for igb i210 firmware issue
    - igb: add i211 to i210 PHY workaround
    - [x86] hyperv: Handle unknown NMIs on one CPU when unknown_nmi_panic
    - PCI: Separate VF BAR updates from standard BAR updates
    - PCI: Remove pci_resource_bar() and pci_iov_resource_bar()
    - PCI: Decouple IORESOURCE_ROM_ENABLE and PCI_ROM_ADDRESS_ENABLE
    - PCI: Don't update VF BARs while VF memory space is enabled
    - PCI: Update BARs using property bits appropriate for type
    - PCI: Ignore BAR updates on virtual functions
    - PCI: Do any VF BAR updates before enabling the BARs
    - [powerpc*] ibmveth: calculate gso_segs for large packets
    - [x86] Drivers: hv: ring_buffer: count on wrap around mappings in
      get_next_pkt_raw() (v2)
    - vfio/spapr: Postpone allocation of userspace version of TCE table
    - [powerpc*] iommu: Stop using @current in mm_iommu_xxx
    - [powerpc*] vfio/spapr: Reference mm in tce_container
    - [powerpc*] mm/iommu, vfio/spapr: Put pages on VFIO container shutdown
    - [powerpc*] vfio/spapr: Add a helper to create default DMA window
    - [powerpc*] vfio/spapr: Postpone default window creation
    - drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices
    - drm/nouveau/disp/nv50-: split chid into chid.ctrl and chid.user
    - drm/nouveau/disp/nv50-: specify ctrl/user separately when constructing
      classes
    - block: allow WRITE_SAME commands with the SG_IO ioctl
    - [s390x] zcrypt: Introduce CEX6 toleration
    - uvcvideo: uvc_scan_fallback() for webcams with broken chain
    - [x86] ACPI / blacklist: add _REV quirks for Dell Precision 5520 and 3520
    - [x86] ACPI / blacklist: Make Dell Latitude 3350 ethernet work
    - serial: 8250_pci: Detach low-level driver during PCI error recovery
    - [armhf] clk: bcm2835: Fix ->fixed_divider of pllh_aux
    - [armhf] drm/vc4: Fix race between page flip completion event and clean-up
    - [armhf] drm/vc4: Fix ->clock_select setting for the VEC encoder
    - [arm64] KVM: VHE: Clear HCR_TGE when invalidating guest TLBs
    - [armhf,arm64] irqchip/gicv3-its: Add workaround for QDF2400 ITS erratum
      0065
    - [x86] tsc: Fix ART for TSC_KNOWN_FREQ
    - [x86] perf: Fix CR4.PCE propagation to use active_mm instead of mm
    - futex: Fix potential use-after-free in FUTEX_REQUEUE_PI
    - futex: Add missing error handling to FUTEX_REQUEUE_PI
    - locking/rwsem: Fix down_write_killable() for
      CONFIG_RWSEM_GENERIC_SPINLOCK=y
    - [powerpc*] crypto: Fix initialisation of crc32c context
    https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.18
    - [armhf] drm/vc4: Fix termination of the initial scan for branch targets.
    - [armhf] drm/vc4: Use runtime autosuspend to avoid thrashing V3D power
      state.
    - qla2xxx: Fix memory leak for abts processing
    - qla2xxx: Fix request queue corruption.
    - [hppa] Optimize flush_kernel_vmap_range and invalidate_kernel_vmap_range
    - [hppa] Fix system shutdown halt
    - perf/core: Fix use-after-free in perf_release()
    - perf/core: Fix event inheritance on fork()
    - NFS prevent double free in async nfs4_exchange_id
    - cpufreq: Fix and clean up show_cpuinfo_cur_freq()
    - [powerpc*] boot: Fix zImage TOC alignment
    - md/raid1/10: fix potential deadlock
    - target/pscsi: Fix TYPE_TAPE + TYPE_MEDIMUM_CHANGER export
    - scsi: lpfc: Add shutdown method for kexec
    - scsi: libiscsi: add lock around task lists to fix list corruption
      regression
    - target: Fix VERIFY_16 handling in sbc_parse_cdb
    - isdn/gigaset: fix NULL-deref at probe
    - gfs2: Avoid alignment hole in struct lm_lockname
    - percpu: acquire pcpu_lock when updating pcpu_nr_empty_pop_pages
    - cgroup/pids: remove spurious suspicious RCU usage warning
    - [x86] drm/amdgpu/si: add dpm quirk for Oland
    - ext4: fix fencepost in s_first_meta_bg validation (Closes: #856808)

  [ Ben Hutchings ]
  * [powerpc*] Ignore ABI changes in cxl (fixes FTBFS) (Closes: #858530)
    and IOMMU setup
  * Ignore ABI changes in bpf, dccp, libiscsi
  * [x86] Ignore ABI changes in kvm
  * [rt] Update to 4.9.18-rt14:
    - lockdep: Fix per-cpu static objects
    - futex: Cleanup variable names for futex_top_waiter()
    - futex: Use smp_store_release() in mark_wake_futex()
    - futex: Remove rt_mutex_deadlock_account_*()
    - futex,rt_mutex: Provide futex specific rt_mutex API
    - futex: Change locking rules
    - futex: Cleanup refcounting
    - futex: Rework inconsistent rt_mutex/futex_q state
    - futex: Pull rt_mutex_futex_unlock() out from under hb->lock
    - futex,rt_mutex: Introduce rt_mutex_init_waiter()
    - futex,rt_mutex: Restructure rt_mutex_finish_proxy_lock()
    - futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()
    - futex: Futex_unlock_pi() determinism
    - futex: Drop hb->lock before enqueueing on the rtmutex
    - futex: workaround migrate_disable/enable in different context
    - Revert "kernel/futex: don't deboost too early"
  * xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window
    (CVE-2017-7184)
  * xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder (CVE-2017-7184)
  * scsi: sg: check length passed to SG_NEXT_CMD_LEN (CVE-2017-7187)
  * [x86] vmwgfx: NULL pointer dereference in vmw_surface_define_ioctl()
    (CVE-2017-7261)
  * [x86] drm/vmwgfx: fix integer overflow in vmw_surface_define_ioctl()
    (CVE-2017-7294)
  * net/packet: Fix integer overflow in various range checks (CVE-2017-7308)
  * [arm64] rtc: tegra: Implement clock handling (Closes: #858514)
  * [armhf] sound/soc: Enable SND_SUN4I_SPDIF as module (Closes: #857410)
  * [arm64,x86] Enable CROS_KBD_LED_BACKLIGHT as module (Closes: #856906)
  * netfilter: nft_ct: add notrack support (Closes: #845500)
  * w1: Enable W1_MASTER_GPIO as module (Closes: #858975)

  [ James Clarke ]
  * [sparc64] udeb: Re-add ufs-modules (Closes: #858049)

[dgit import unpatched linux 4.9.18-1]

Import linux_4.9.18.orig.tar.xz

[dgit import orig linux_4.9.18.orig.tar.xz]